In multi-element networks including networks incorporating multiprocessor systems it is frequently desirable for each network element and microprocessor to have a common real time stamp. This real time information will typically include a range of time components including year, month, day, hour, minute, etc. The information may be required for a number of reasons including but not limited to billing and debugging. In a billing application, for example, a multi-element network might be associated with a communication system in which it is important that the element that records timing data and the element that services a connection have a common date and time reference. In a debugging application accurate sequence timing information can prove extremely important in isolating a network or system problem. Although a time stamp for billing purposes may involve relatively low precision timing levels such as day, hour, minute, and second, debugging requirements may involve high precision timing references, down to the microsecond range. Having a common platform that will service both needs will keep resources down.
In any event there is a requirement in multi-element networks to provide a real time stamp which may range, for example, from the current year down to the exact microsecond. Ideally, the broad range of time stamp information is distributed by a single system to preserve scarce system resources.
At present, multiprocessing systems and multi-element networks send time of day information from a master timekeeping element to other processors and elements of the system through software messages. Software messages are typically carried over shared buses and as such are subject to network delays and system failures. Low precision timing information is generally not problematic while high precision time stamps tend to be unreliable. The delay introduced by the network may result in the time stamp arriving at an element after the valid time. System failure and particularly a fault in the master element will result in the time stamp not being delivered at all. A second problem with software messaging is that in order to achieve a certain level of accuracy time stamps must be delivered frequently. This can result in a significant portion of a system's resources being dedicated to time stamp distribution rather than using system bandwidth for its intended functionality.